1. Field of the Invention
The present invention relates to atomic transactional updates in a transaction processing system and more particularly to replication of transactionally updated data in a transaction processing system.
2. Description of the Related Art
A transaction processing system is a type of information system that collects, stores, modifies, and retrieves organizational transactions. In this regard, a transaction is an event that generates or modifies data that is eventually stored in an information system. To be considered a transaction processing system the “ACID” test must be satisfied. In this regard, the “ACID” test refers to a test for atomicity, consistency, isolation, durability as a set of properties that guarantee database transactions are processed reliably.
The essence of a transaction processing system is that the data of the transaction processing system data must be left in a consistent state. That is to say, for a compound transaction, for the transaction to complete successfully, all portions of the transaction must complete successfully. Otherwise, any changes resulting from the partial completion of the transaction must be “rolled back” to the state that existed prior to the initiation of the compound transaction. While this type of integrity must be provided also for batch transaction processing, it is particularly important for real time processing. Other transaction monitor functions include deadlock detection and resolution resulting from cross-dependence on data, and transaction logging in trace logs for forward recovery in case of transaction failures requiring debugging.
Transaction processing is not limited to a centralized computing architecture. Rather, as a matter of best practices, transaction processing has been deployed within a distributed computing architecture. Within a distributed computing architecture, different servers, whether virtual or real, replicate data between one another so that each server maintains an identical set of working data thereby permitting the manipulation of the data in any selected server. Consequently, redundancy can be achieved for the purpose of high availability or disaster recovery, without requiring an end user to remain captive to any particular one of the servers. Yet, while advantageous, replicating data in a transaction processing system is not without its perils.
In this regard, when performing replication in a transaction processing system, only updates to records that are not to be rolled back and are committed should be replicated to a different server so that the data in the different server is not exposed to data inconsistency in the event that the data is rolled back in the origin server. To combat this potential inconsistency, log files are typically employed such that the different server can inspect the log file to determine whether or not replicated data need also be rolled back as it had been on a source server. However, where multiple log files are employed, coordinating a common understanding of updates and roll backs to ensure consistency in replication can be challenging.